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Abstract 


This  report  examines  Section  804  National  Defense  Authorization  Act  (NDAA)  for  2010  and  re¬ 
lated  guidance  documents  through  the  lens  of  the  Department  of  Defense  (DoD)  Infonnation 
Technology  (IT)  Program  Manager.  The  information  in  this  report  is  intended  to  help  the  program 
manager  reason  about  actions  they  may  need  to  take  to  adapt  and  comply  with  the  Section  804 
NDAA  for  2010  and  associated  guidance. 
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Executive  Summary 


In  this  report,  we  look  at  Section  804  National  Defense  Authorization  Act  (NDAA)  for  2010  and 
related  guidance  documents,  at  the  time  this  report  was  written,  through  the  lens  of  the  Depart¬ 
ment  of  Defense  (DoD)  Information  Technology  (IT)  program  manager.  It  is  the  author’s  hope 
that  this  information  will  enable  the  program  manager  to  reason  about  building  expertise,  chang¬ 
ing  internal  processes,  and  leveraging  new  toolsets  to  adapt  to  the  new  IT  acquisition  process. 

In  the  first  part  of  this  report,  the  author  analyzes  three  IT  acquisition-related  documents.  For  each 
document,  the  author  provides  a  brief  summary  of  the  contents  of  the  document  followed  by  key 
program  management  implications.  The  documents  analyzed  in  this  report  include: 

•  Section  804  National  Defense  Authorization  Act  for  20 1 0 

•  Interim  Acquisition  Guidance  for  Defense  Business  Systems  (DBS)  released  November  2010 

•  A  New  Approach  for  Delivering  Information  Capabilities  in  the  Department  of  Defense  re¬ 
leased  November  20 1 0 

Section  5  contains  a  roll  up  of  the  program  manager  implications  from  each  section  of  this  paper 
into  a  summary  table  titled  “DoD  804-Related  Program  Manager  Considerations.”  The  paper  con¬ 
cludes  with  a  summary  of  ongoing  work  related  to  IT  acquisition  reform  and  closing  thoughts. 
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1  Introduction 


1.1  Background 

At  the  request  of  Congress,  the  Defense  Science  Board  (DSB)  conducted  a  study  released  in 
March  2009  to  evaluate  the  current  acquisition  process  for  Information  Technology  (IT)  systems 
in  the  DoD.  The  output  of  the  study  was  a  report  proposing  that  the  Undersecretary  of  Defense 
create  a  new  acquisition  process  for  IT  systems  based  on  commercial  worldwide  best  practices 
[DSB  2009].  The  study  pointed  out  that  the  new  process  should  foster  industry  standard  practices, 
such  as  requiring  continuous  user  participation  throughout  the  software  lifecycle  and  mandating 
iteration-driven  software  development  approaches. 

In  response  to  the  DSB  recommendation,  Congress  passed  the  Section  804  National  Defense  Au¬ 
thorization  Act  (NDAA)  for  2010,  which  called  for  the  Under  Secretary  of  Defense,  Dr.  Ashton 
B.  Carter,  to  develop  and  implement  a  new  acquisition  process  for  IT  systems  [Ren  2010].  Carter 
then  released  an  Interim  Acquisition  Guidance  for  Defense  Business  Systems  on  November  15, 
2010.  This  guidance  provided  program  managers  with  a  transitional  IT  acquisition  process  while 
they  waited  for  the  new  IT  acquisition  process  to  be  released. 

The  DoD  then  released  a  report  titled,  A  New  Approach  for  Delivering  Information  Capabilities 
in  the  DoD,  in  which  the  Secretary  of  Defense,  responding  to  Section  804,  provides  an  update  on 
DoD’s  progress  towards  developing  a  new  IT  acquisition  process.  In  the  “New  Approach”  report, 
the  Under  Secretary  of  Defense  provides  some  rough  implementation  guidelines,  as  well  as  gen¬ 
eralized  set  of  system  categories  for  program  managers  to  leverage  in  trying  to  determine  whether 
the  new  IT  acquisition  process  applies  or  not. 

This  report  looks  at  these  important  documents  from  the  perspective  the  program  manager  respon¬ 
sible  for  responding  to  the  impact  of  the  proposed  changes  on  their  program(s). 

1.2  Brief  Overview 

The  purpose  of  this  report  is  to  help  the  DoD  IT  System  Program  Managers  reason  about  what 
actions  they  may  need  to  take  to  adapt  and  comply  with  the  Section  804  NDAA  for  2010  and  as¬ 
sociated  guidance. 

This  report  contains  an  analysis  of  the  following  documents: 

•  Section  804  NDAA  for  20 1 0 

•  Interim  Acquisition  Guidance  for  Defense  Business  Systems  (DBS)  released  November  2010 

•  A  New  Approach  for  Delivering  Information  Capabilities  in  the  Department  of  Defense  re¬ 
leased  Nov  2010 
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The  sections  in  the  body  of  this  report  follow  a  consistent  format  with  the  following  subsections: 

•  Applicability  (to  whom  the  guidance  is  applicable) 

•  Key  Dates  (key  dates  identified  in  the  report  or  directive) 

•  Overview  (brief  description  of  the  report  or  directive) 

•  Program  Management  Impacts  related  to  the  Guidance 

Section  5  of  this  paper  contains  a  consolidation  of  the  program  manager  implications  from  each 
section  into  a  combined  summary  table  titled  “DoD  Program  Manager  Considerations”.  The  paper 
concludes  with  a  summary  of  ongoing  work. 

1.3  Scope 

Section  804  NDAA  for  2010  has  sweeping  implications  for  DoD  programs  across  the  entire  IT 
acquisition  lifecycle.  It  covers  the  investment  review  stage  through  to  the  various  activities  within 
the  engineering  phase  (i.e.,  requirements,  design,  testing).  We  are  not  going  to  cover  all  potential 
impacts  across  the  entire  acquisition  landscape  in  this  paper.  We  have  scoped  this  report  to  focus 
on  topics  relevant  to  the  DoD  IT  Program  Manager  and  the  software  development  lifecycle. 
Therefore,  we  focused  special  attention  on  the  phase  after  the  business  case/investment  review 
phase,  the  engineering  phase,  and  topics  related  to  the  engineering  phase.  This  includes  topics 
related  to  managing  and  executing  the  development  of  software-intensive  IT  systems. 

Related  topics  that  are  out  of  scope  for  this  paper  include: 

•  business  case  development 

•  investment  review 

•  governance 

•  policy 

•  operations  and  sustainment 

In  the  next  section,  we  begin  our  brief  overview  of  the  contents  of  Section  804  NDAA  for  2010. 
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2  National  Defense  Authorization  Act,  Section  804 


In  this  section,  we  briefly  summarize  the  Section  804  NDAA  for  2010. 

2.1  Applicability 

Section  804  NDAA  for  2010  directs  the  Secretary  of  Defense  to  implement  a  new  acquisition  pro¬ 
cess  for  IT  systems. 

2.2  Key  Dates 

This  section  summarizes  any  key  dates  specified  in  the  Section  804  NDAA  for  2010  guidance. 
This  Act  specifies  that  the  Secretary  of  Defense  must  submit  a  report  to  Congress  no  later  than 
270  days  after  the  date  of  the  enactment  of  the  Act,  December  2010. 

2.3  Overview 

This  section  provides  a  brief  overview  of  the  Act.  Congress  approved  the  Section  804  NDAA  for 
2010  titled  “Implementation  of  New  Acquisition  Process  for  Information  Technology  Systems”  in 
December  2010.  Highlights  from  this  Act  are  paraphrased  in  the  following  paragraphs.  Because 
these  concepts  are  relatively  new  within  the  DoD,  the  directive  at  this  stage  is  relatively  brief  and 
vague.  The  Act  specifies  that  the  Secretary  of  Defense  shall  provide  a  report  to  Congress  that: 

•  describes  the  new  acquisition  process  and  provides  an  explanation  for  any  decision  by  the 
Secretary  to  deviate  from  the  criteria 

•  defines  paragraphs  (1)  and  (2)  of  subsection  (a)  of  Section  804  NDAA  for  2010 

•  provides  a  schedule  for  the  implementation  of  the  new  acquisition  process 

•  identifies  the  categories  of  information  technology  acquisitions  to  which  such  process  will 
apply 

•  and  includes  the  Secretary's  recommendations  for  any  legislation  that  may  be  required  to 
implement  the  new  acquisition  process  [NDAA  2010], 

Appendix  A  provides  the  full  text  of  the  Section  804  NDAA  for  2010. 

2.4  Program  Management  Impacts  Based  on  This  Guidance 

The  directive  is  very  short;  however,  its  four  key  bullets  have  broad  and  sweeping  implications 
for  the  IT  Program  Manager.  They  specify  that  the  new  process  shall  foster: 

•  early  and  continual  involvement  of  the  user 

•  multiple,  rapidly  executed  increments  or  releases  of  capability 

•  early,  successive  prototyping  to  support  an  evolutionary’  approach 

•  a  modular,  open-systems  approach 
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3  Interim  Acquisition  Guidance  for  Defense  Business 
Systems  Released  November  2010 


On  November  15,  2010,  Dr.  Ashton  B.  Carter  released  an  “Interim  Acquisition  Guidance  for  De¬ 
fense  Business  Systems  (DBS).”  The  intent  of  this  guidance  was  to  provide  a  transitional  acquisi¬ 
tion  process  for  DoD  programs  to  use  until  the  new  IT  acquisition  process  is  released. 

3.1  Applicability 

The  DBS  specifies  that  the  interim  guidance  is  applicable  to: 

•  the  Office  of  Secretary  of  Defense 

•  the  military  departments 

•  the  Office  of  the  Chairman  of  the  Joint  Chiefs  of  Staff  (CJCS)  and  the  Joint  Staff 

•  the  Combatant  Commands 

•  the  Office  of  the  Inspector  General  of  the  Department  of  Defense 

•  the  Defense  Agencies 

•  the  DoD  Field  Activities 

•  and  all  other  organizational  entities  within  the  DoD 

The  DBS  also  specifies  the  dollar- value  threshold  for  the  applicability  of  a  new  process  called  the 
Business  Capability  Lifecycle  (BCL).  The  interim  guidance  states  that  the  BCL  shall  apply  to 
each  defense  business  system  with  a  total  modernization  cost  over  $1,000,000. 

3.2  Key  Dates 

This  guidance  states  that  its  effective  date  is  November  2010,  and  that  the  directive  will  remain  in 
effect  until  formally  incorporated  into  DoD  Instruction  (DoDI)  5000.02  [Interim  Report  2010]. 

3.3  Overview 

As  expected  in  an  interim  guidance  document,  this  directive  straddles  the  new  and  the  old  acquisi¬ 
tion  processes.  For  example,  it  suggests  a  beta  release  concept  and  at  the  same  time  requires  full 
operational  test  and  evaluation  (OT&E)  for  the  beta  release.  This  raises  the  question,  “What  is  the 
difference  between  a  beta  and  non-beta  release  if  a  Beta  requires  full  OT&E?”  Clearly,  this  is  in¬ 
terim  guidance  that  is  trying  to  move  in  the  direction  of  new  acquisition  concepts,  but  is  still  hold¬ 
ing  rather  tightly  to  the  old. 


The  interim  guidance  describes  changes  to  each  of  the  following  phases  (shown  in  Figure  1): 

•  Business  Capability  Definition/Investment  Review 

•  Architectural  Development  and  Risk  Reduction  (Prototypes) 

•  Development  and  Demonstration 

•  Operations  and  Support 
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A  significant  portion  of  this  guidance  document  focuses  on  the  impact  to  the  Business  Case  Anal¬ 
ysis  and  development  phase.  Consequently,  there  is  less  focus  on  the  Architectural  Development 
and  Risk  Reduction  phase,  Development  and  Demonstration  phase,  and  Operations  and  Support 
phase.  The  focus  area  for  this  guidance  document  is  shown  in  the  figure  below. 


DSB  Recommended 
Acquisition  Process 
for  IT  Systems 


/laterial  Development  ♦  Decision 
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Development 
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and  Risk  Reduction 

pment 
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Coordinated  DoD  Stakeh 
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kehaldeiTnvoh 
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J  L 
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Later  Relea 


Figure  1:  Defense  Science  Board  Recommended  Acquisition  Process  [Ren  2010] 

Although  the  guidance  is  short,  it  is  impactful.  This  interim  guidance  states  that  programs  shall 
incorporate  the  following: 

•  Incremental  Approach — An  approved  business  need  shall  be  divided  into  discrete,  frilly  fund¬ 
ed,  and  manageable  increments  and  shall  adhere  to  the  maximum  requirements  for  an  incre¬ 
ment  (specified  in  this  guidance). 

•  Independent  Assessment — An  independent  risk  assessment  shall  be  performed  prior  to  Mile¬ 
stone  A  and  Milestone  B  and  serve  as  input  for  the  investment  review  board  review. 

•  BCL  Acquisition  Business  Model — The  BCL  shall  be  used  as  the  model  acquisition  process 
for  DBS.  The  guidance  provides  procedures  for  meeting  BCL  and  DBS  requirements  [Interim 
Report  2010]. 

3.4  Business  Capability  Lifecycle 

The  most  significant  part  of  the  directive  for  the  program  manager  in  the  interim  guidance  is 
probably  the  requirement  to  use  the  BCL  model  as  the  new  acquisition  process  for  defense  busi¬ 
ness  systems  (until  the  new  process  is  finalized).  The  guidance  doesn’t  apply  to  all  programs, 
however.  The  guidance  specifies  that  the  BCL  shall  apply  to  each  DBS  that  has  a  total  moderniza¬ 
tion  cost  over  $1,000,000. 


BCL  merges  three  major  DoD  processes: 

1.  CJCSI  3170. 01G,  Joint  Capabilities  Integration  and  Development  System  (JCIDS) 

2.  DoDI  5000.02  Operation  of  the  Defense  Acquisition  System  (DAS) 

3.  Investment  Review  Board  (IRB)  /  Defense  Business  System  Management  Committee 
(DBSMC)  governance  bodies  for  defense  business  capabilities  and  systems 

The  BCL  acquisition  business  model  (see  Figure  2)  supports  the  implementation  of  BCL  and  de¬ 
picts  the  phases,  milestones,  and  decision  points  of  the  BCL  acquisition  process. 
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Figure  2:  BCL  Acquisition  Business  Model  [Interim  Report  201 0] 


Key  attributes  of  BCL  include 

•  streamlined  capability  documentation 

•  streamlined  governance  and  tiered  accountability 

•  independent  risk  assessment 

•  flexibility  in  capability  implementation  strategies 

•  emphasis  on  the  use  of  mature  technologies 

•  use  of  “time  constrained”  process  management  and  program  execution 

•  capability  delivery  in  increments  of  1 8  months  or  less 

•  user  and  test  communities  engagement  throughout  the  lifecycle  [New  Approach  2010] 


3.5  Program  Management  Impacts  Based  on  This  Guidance 

As  mentioned  earlier  in  this  section,  a  significant  portion  of  this  guidance  is  focused  on  the  phases 
prior  to  the  Development  and  Demonstration  Phase  such  as  the  Investment  Review/Business  Case 
Development  phases.  Since  this  phase  is  largely  out  of  the  program  manager’s  control,  the  bullet 
list  below  provides  a  condensed  list  of  directives  from  the  guidance  that  specifically  affect  the 
program  manager’s  sphere  of  influence. 

To  help  organize  and  reason  about  the  impact  on  program  managers,  these  areas  of  impact  are 
grouped  into  the  following  categories:  Planning  and  Portfolio  Management,  Prototyping,  Re¬ 
quirements  and  Architecture,  Development  and  Execution,  Testing,  Project  Monitoring  and  Re¬ 
porting. 
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Planning  and  Portfolio  Management 

•  1 8  months  specified  as  maximum  time  that  shall  elapse  between  contract  full  deployment 

•  Initial  Operating  Capability  must  be  achievable  within  5  years 

Prototyping,  Requirements  and  Architecture 

•  Prototyping  shall  be  used  as  a  continuous  discovery  and  development  process  reflecting  close 
collaboration  between  the  functional  sponsor  and  the  system  developer 

•  Knowledge  gained  during  prototyping  may  result  in  changes  to  the  requirements 

•  Funding  for  prototyping  activities  must  be  approved  by  the  milestone  decision  authority 

Testing 

•  The  guidance  introduces  the  concept  of  the  Limited  Deployment  Phase  in  which  limited 
number  of  users  get  access  to  a  new  “beta”  release  and  test  it  in  an  operational  environment 

•  The  Limited  Deployment  Phase  entrance  criteria  is  defined  as  a  developmentally-tested,  pro¬ 
duction-representative  system,  and  ready  for  initial  operational  test  and  evaluation 

Development  and  Execution 

•  Requires  that  at  Full  Deployment  Decision,  the  milestone  decision  authority  shall  review  the 
business  case  and  the  independent  operational  testing  and  evaluation  results  and  make  rec¬ 
ommendations  whether  the  capability  is  ready  to  proceed  to  full  deployment 

Project  Monitoring  and  Reporting 

•  Specifies  each  increment  shall  include  a  close-out  review 

•  Explains  that  the  close-out  review  enables  understanding  of  how  well  a  completed  increment 
meets  the  needs  of  users  before  finalizing  the  requirements  for  a  subsequent  increment 

The  next  section  describes  the  Secretary  of  Defense’s  response  to  Section  804  NDAA  for  2010. 
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4  DoD  Response  to  804:  A  New  Approach  for  Delivering 
Information  Capabilities  in  the  Department  of  Defense 


The  next  piece  of  information  related  to  804  is  a  report  titled,  “A  New  Approach  for  Delivering 
Information  Capabilities  in  the  DoD”.  This  is  the  Secretary  of  Defense’s  response  to  Section  804 
NDAA  for  2010. 

4.1  Applicability 

While  the  new  process  is  applicable  across  all  DoD  IT  systems,  this  report  specifies  that  the  new 
IT  acquisition  process  does  not  apply  to  all  categories  of  systems.  The  report  states  that  the  new 
acquisition  process  is  applicable  to  the  following  types  of  systems: 

Networked  IT  Systems  (e.g.,  command  and  control,  business  information) 

•  user-facing  applications 

•  computing  infrastructure  (e.g.,  common  applications,  operating  system) 

•  security  and  information  assurance  for  applications,  systems,  and  networks 

•  computing  hardware  including  configuration  modification  for  network  integration,  etc.  (e.g., 
servers,  laptops) 

•  communications/networking  infrastructure 

Note:  IT  hardware  requiring  unique  development  and  requisite  production  decisions  will  be  ac¬ 
quired  using  traditional  DoD  acquisition  policy  (DoD  5000  processes)  to  ensure  appropriate  fo¬ 
cus  on  these  areas. 

Weapon  Platform  IT  Systems 

•  platform-hosted  IT  mission  systems  that  are  not  considered  embedded 

Note:  IT  embedded  in  weapon  systems  will  continue  to  be  developed,  acquired,  and  managed  as 
part  of  that  weapon  platform  and  not  separately  acquired  under  the  new  IT  acquisition  process. 
Upgrades  to  embedded  IT  software  in  weapon  systems  may  be  considered  for  applicability  to  the 
new  IT  acquisition  process  when  no  hardware  change  is  required. 

Sendees  acquired  or  developed  as  a  sendee-oriented  architecture  [New  Approach  2010] 
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4.2  Key  Dates 

This  report  does  not  provide  specific  implementation  dates;  however,  it  does  provide  a  rough  im¬ 
plementation  schedule  summarized  as  follows. 

Near-term  schedule  requirements: 

•  designate  initial  pilot  projects  (new  start  projects  and  existing  programs)  aligned  within  each 
broad  portfolio 

•  initiate  aspects  of  the  new  process  not  requiring  legislative  changes 

•  determine  and  implement  project  performance-tracking  metrics  and  tools 

•  engage  with  industry  associations  to  gather  their  input  in  developing  the  new  process 

•  define  the  organizational  structure  and  designate  portfolios  within  the  information  enterprise 

•  complete  development  of  the  project  templates 

•  develop  DoD  policy  issuances  to  apportion  roles  and  responsibilities,  authorities,  and  ac¬ 
countabilities  within  the  new  process 

•  define  platform  standards  and  common  test  and  integration  capabilities  in  consultation  with 
the  DoD  CIO 

•  develop  interim  training  curriculum  and  initiate  training 

•  exploit  existing  mechanisms  for  execution  year  resourcing  flexibility 

•  develop  legislative  proposal  for  FY12 

Mid-term  schedule  requirements : 

•  expand  set  of pilot  projects  to  fine-tune  the  new  processes  and  initiate  pilot  portfolio 

•  further  develop  training  curriculum  and  expand  staff  training 

•  submit  proposed  legislative  changes  for  FY12 

4.3  Overview 

The  report  titled  “A  New  Approach  for  Delivering  Information  Capabilities  in  the  DoD”  is  the 
Secretary  of  Defense’s  response  to  Section  804  NDAA  for  2010  and  provides  an  update  on  DoD’s 
progress  towards  developing  a  new  acquisition  process  for  information  technology  systems.  The 
report  highlights  that  significant  and  fundamental  change  is  needed  across  the  department’s  IT 
acquisition  processes,  with  synchronized  and  risk-scaled  requirements,  resourcing,  acquisition 
management  and  oversight  in  order  to  deliver  rapid  IT  capabilities  where  they  are  needed  most 
[Press  Release  2010]. 
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This  section  includes 

•  a  description  of  the  new  acquisition  process 

•  explanations  of  deviations  from  the  DSB  report 

•  an  implementation  schedule 

•  identification  of  the  applicable  categories  of  IT 

•  recommendations  for  legislative  change  considerations  [New  Approach  20 1 0] 

Contrary  to  the  interim  guidance,  where  significant  focus  is  placed  on  areas  such  as  Business  Case 
Analysis  and  Development,  the  focus  of  this  guidance  is  on  the  Development  and  Demonstration 
Phase. 


DSB  Recommended 
Acquisition  Process 
for  IT  Systems 


♦  Material  Development  ♦  Decision 
Decision  Point 


Business  Case 
Analysis  and 
Development 


- 1 - 

Coordinated  DoD  Stakeholder  Involvem^i 


Architect  urn  I  Development 
and  Risk  Reduction 


Prototypes 


Later  Rele 


Figure  3:  Defense  Science  Board  Recommended  Acquisition  Process  II  [Ren  2010] 


In  the  New  Approach  report,  the  IT  task  force  defined  several  principles  to  guide  the  department’s 
approach  to  IT  acquisition  including: 


•  Deliver  early  and  often:  This  principle  is  aimed  at  changing  the  culture  from  one  that  is  fo¬ 
cused  typically  on  a  single  delivery  to  a  new  model  that  comprises  multiple  deliveries  to  es¬ 
tablish  an  environment  that  supports  deployed  capabilities  every  12  to  18  months. 

•  Incremental  and  iterative  development  and  testing:  This  principle  embraces  the  concept  that 
incremental  and  iterative  development  and  testing,  including  the  use  of  prototyping,  yield  bet¬ 
ter  outcomes  than  trying  to  deploy  large,  complex  IT  network  systems  in  one  big  bang. 

•  Rationalized  requirements:  User  involvement  is  critical  to  the  ultimate  success  of  any  IT  im¬ 
plementation,  and  user  needs  must  be  met.  However,  this  principle  also  recognizes  the  need 
for  users  and  requirements  developers  to  embrace  an  enterprise  focus  across  a  portfolio  of  ca¬ 
pabilities  with  established  standards  and  open  modular  platforms  that  offer  customized  solu¬ 
tions  to  ensure  interoperability  and  seamless  integration. 

•  Flexible  and  tailored  processes:  The  department’s  IT  needs  range  from  modernizing  nuclear 
command  and  control  systems  to  updating  word  processing  systems  on  office  computers.  This 
principle  acknowledges  unique  types  of  IT  acquisition  and  embraces  flexible  and  tailored — 
and  risk-appropriate — IT  paths  based  on  the  characteristics  of  the  proposed  IT  acquisition. 

•  Knowledgeable  and  experienced  IT  workforce:  This  task  force  recognizes  that  a  top  priority 
is  to  establish  a  cadre  of  trained  professionals  and  that  the  lack  thereof  is  a  significant  imped¬ 
iment  to  successful  implementation  of  any  future  process  [New  Approach  2010], 
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4.4  Program  Management  Impacts  Based  on  This  Guidance 


As  mentioned  in  the  overview  for  this  section,  a  significant  portion  of  this  guidance  is  focused  on 
the  Engineering  Phase  (Development  and  Demonstration  Phase).  A  condensed  list  of  directives 
from  the  guidance  related  to  the  program  manager  is  provided  below.  The  directives  are  grouped 
into  these  broad  categories:  Planning  and  Portfolio  Management,  Requirements,  Architecture, 
Development  and  Execution,  Testing,  Project  Monitoring  and  Reporting. 

Planning  and  Portfolio  Management 

•  New  approaches  should  embrace  the  value  of  “80  percent  solutions”  (as  appropriate). 

•  There  are  different  types  of  systems  and  multiple  acquisition  processes  are  needed  to  address 
the  differences  in  these  types  of  systems. 

•  Projects  executed  in  a  timeboxed  manner  deliver  capability  more  rapidly. 

•  Capabilities  shall  be  deployed  every  12-18  months  and  functionality  that  cannot  be  delivered 
within  timeboxed  constraints  may  be  deferred. 

•  Planning  for  IT  capability  will  require  sequencing  of  prioritized  capabilities. 

•  Portfolio  and  project  management  processes  will  move  from  large  multi-year  programs  to 
portfolios  of  short-duration  projects. 

•  More  emphasis  on  timely  coordination  and  quicker  decision-making  will  be  delegated  to  low¬ 
er  levels  for  smaller  projects,  but  with  accountability  mechanisms  for  senior-level  decision¬ 
making. 

•  A  multi-level  planning  approach  will  be  used,  with  a  multi-year  roadmap  and  a  12  month  de¬ 
tailed  release  plan. 

•  Investment  approach  will  fund  multiple  time -boxed,  overlapping  projects. 

•  Team  members  of  interrelated  projects  will  provide  incremental  iterative  IT  capability  im¬ 
provements  through  frequent  upgrades. 

Prototyping,  Requirements  and  Architecture 

•  Requirements  management  process  will  be  adjusted  to  reflect  timeboxed  development  con¬ 
straints  and  allow  for  uncertainty. 

•  Initial  requirements  will  be  defined  at  the  mission  level  in  broad,  measurable  terms  that  are 
not  expected  to  change  (e.g.,  appropriate  cyber  security  controls,  data  standards,  process 
flows,  architecture,  and  minimum  system  specific  key  performance). 

•  Prioritization  and  further  definition  of  requirements  will  be  an  ongoing  activity. 

•  Tools  and  methods  will  be  furnished  to  prioritize  requirements  and  facilitate  user  feedback. 

•  Users  from  joint  or  service/agency  organizations  will  be  designated  to  serve  as  requirements 
leads  to  participate  in  oversight  reviews. 

•  Enterprise  focus,  established  standards,  and  open  modularity  will  drive  and  constrain  designs 
to  ensure  interoperability  and  seamless  integration. 

•  Multi-year  roadmap  and  detailed  release  plans  will  be  supported  by  business  and  technical 
architectures  and  standards. 
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•  Development  efforts  shall  allow  for  user-determined  priorities. 

Development  and  Execution 

•  As  applicable,  innovative  approaches  such  as  user-centered  design,  feature-driven  develop¬ 
ments,  and  other  proven  IT  practices  should  be  considered. 

•  Development  efforts  will  focus  on  what  can  be  achieved  in  the  short  term. 

•  Development  efforts  shall  be  based  on  low-risk  technology. 

•  Continuous  user  engagement  will  be  emphasized  throughout  the  process. 

•  Development,  when  necessary,  will  include  prototyping  and  maturity  assessment  activities. 

Testing 

•  Development  will  involve  continual  test  and  evaluation  with  user  involvement. 

•  Test  and  evaluation  will  be  structured  to  support  iterative  and  incremental  delivery. 

•  Testing  approaches  will  make  extensive  use  of  prototyping  and  automated  testing. 

•  Testing  will  be  integrated  with  certification  and  accreditation  activities. 

•  Testing  processes  will  leverage  in-situ  testing  on  beta  versions  prior  to  release. 

•  Integrate  existing  test  infrastructure  into  a  persistent,  virtual,  service-based  environment. 

Project  Monitoring  and  Reporting 

•  Increase  the  stakeholder  involvement  through  more  frequent  performance-based,  in-process 
reviews. 

•  Tangible  evidence  of  relevant  development  capabilities  in  the  form  of  prototypes  or  deployed 
systems  (“working  software”)  will  have  preference  in  an  evaluation  with  a  commensurate  de¬ 
crease  in  paper-based  proposal  components. 

•  Traditional  milestone  reviews  to  initiate  major  DoD  5000  program  phases  will  be  realigned  to 
address  milestone  decision  points. 

•  These  milestone  decision  points  will  be  conducted  as  in-process  reviews  for  decision-makers 
to  obtain  real-time  program  status  for  acquisition  decisions. 

•  In  earlier  phases  of  the  acquisition,  stakeholder  reviews  should  be  calendar-based  events, 
while  later  phases  should  link  such  reviews  with  iterations  or  delivery  of  capability. 

•  Project  status  and  execution  information  will  be  available  electronically,  replacing  paper- 
based  reporting. 

•  Documentation  will  be  consolidated. 

W  orkforce/Other 

•  Acquiring  highly  trained  IT  professionals  is  a  top  priority. 

•  Outreach  to  industry  will  be  conducted  to  gain  insight  into  commercially  driven  industry 
trends. 
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5  Section  804  Program  Manager  Considerations  Summary 
Table 


This  section  contains  a  consolidated  summary  of  the  program  manager  implications  from  each  of 
the  previous  sections.  The  summary  table  is  organized  according  to  following  columns:  Category 
(specifies  a  general  grouping  concept),  Directive,  Source  (source  document),  and  PM  Considera¬ 
tions.  Many  of  items  in  the  PM  Considerations  column  were  derived  from  the  report  titled  “Con¬ 
siderations  for  Using  Agile  in  DoD  Acquisition”  [Lapham  2010], 


Table  1:  Summary  of  DoD  804-Related  Program  Manager  Considerations 


Category 

Directive 

Source(s) 

PM  Considerations 

Overarching 

Themes 

Early  and  continual 
involvement  of  the  user 

NDAA  Section 

804  FY  2010,  A 

New  Approach: 
Guiding  Principles 

How  will  you  involve  the  user  in  prototyp¬ 
ing? 

How  will  you  involve  the  user  in  require¬ 
ments? 

How  will  you  involve  the  user  in  testing 
activities? 

Incremental  and  iterative 
development  and  testing 

NDAA  Section 

804  FY  2010, 

New  Approach: 
Guiding  Principles 

Do  planning  processes  support  iterative 
planning? 

Do  you  have  a  way  to  determine  whether 
system  functionality  can  be  divided  to 
support  iterative  releases  (e.g.,  architec¬ 
tural  dependency  analysis)  [arch  de¬ 
pendency] 

Does  the  development  team  have  exper¬ 
tise  and  tools  to  develop  software  incre¬ 
mentally  (e.g.,  Agile,  etc.) 

What  criteria  will  be  used  to  decide  which 
increments  will  be  released  to  the  user 
community  and  which  will  be  “internal 
demos”? 

Will  testing  criteria  for  an  iteration  re¬ 
lease  be  different  from  traditional  testing 
criteria? 

Will  testing  processes  vary  for  internal 
versus  external  releases? 

Early,  successive  proto¬ 
typing  to  support  an 
evolutionary  approach 

NDAA  Section 

804  FY  2010 

Do  you  have  prototyping  environments? 
Are  prototyping  environments  separate 
from  your  production  and  testing  envi¬ 
ronments  for  “beta  testing”? 

A  modular,  open- 
systems  approach 

NDAA  Section 

804  FY  2010 

Do  you  have  common  definition  for  mod¬ 
ular,  open  systems  agreed  upon  by  the 
contractor  and  program  office? 

How  do  you  measure  modular,  open 
system  capability? 

Flexible/Tailored  pro¬ 
cesses:  Unique  types  of 

IT  acquisition  and  sys¬ 
tem  characteristics  re¬ 
quire  different  processes 

New  Approach 
Report;  Guiding 
Principles 

Do  you  know  the  differentiating  charac¬ 
teristics  between  systems? 

How  do  you  decide  which  acquisition 
process  to  use? 

What  do  you  need  to  tailor  IT  acquisition 
processes? 
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Category 

Directive 

Source(s) 

PM  Considerations 

Knowledgeable  and 
Experienced  IT  Work¬ 
force 

New  Approach 
Report;  Guiding 
Principles 

Do  you  have  staff  with  experience  man¬ 
aging  systems  development  in  an  incre¬ 
mental  and  iterative  way? 

Is  your  contractor  able  to  develop  in  an 
iterative  and  incremental  way? 

Processes  must  recog¬ 
nize  the  value  of  80 
percent  solutions  and 
development  shall  focus 
on  what  can  be 
achieved  in  the  short 
term  leveraging  “low-risk 
technology” 

New  Approach 
Report 

Do  you  have  a  way  to  determine  what 

80%  of  functionality  is  critical? 

If  you  focus  on  short  term,  how  do  you 
plan  for  infrastructure  and  architecture 
components  on  which  short  term  needs 
depend? 

How  do  you  define  “low  risk  technology” 
on  your  program? 

Planning,  Portfo¬ 
lio  Management 
&  Funding 

Max  time  that  shall 
elapse  between  contract 
initiation  and  full  de¬ 
ployment  is  18  months 
and  Initial  Operating 
Capability  (IOC)  must  be 
achievable  within  5 
years;  Usable  function¬ 
ality  delivered  every  six 
months  (Fed  CIO) 

Interim  Guidance, 
New  Approach 
Report,  25  Point 
Plan  (Fed  CIO) 

Can  your  development  team  support  a  6- 
month  delivery  cycle  if  it  is  mandated? 
What  are  the  risks  to  doing  this? 

Can  you  deliver  full  capability  deploy¬ 
ment  in  18  months? 

Is  IOC  achievable  in  5  years?  If  not,  what 
actions  do  you  need  to  take  (e.g.,  re¬ 
scoping,  add  resources,  etc.) 

Planning  for  IT  capability 
will  require  sequencing 
of  prioritized  capabilities 

New  Approach 
Report 

How  does  your  planning  processes  sup¬ 
port  prioritizing,  by  features  or  capabili¬ 
ties? 

Do  you  have  strong  change  processes 
for  arbitrating  priorities  between  conflict¬ 
ing  stakeholders? 

Portfolio  and  project 
management  processes 
will  move  from  large 
multi-year  programs  to 
portfolios  of  short- 
duration  projects;  A 
multi-level  planning 
approach  will  be  used; 
multi-year  roadmap  and 
a  12  month  detailed 
release  plan 

New  Approach 
Report 

Do  you  have  portfolio  management  pro¬ 
cesses  and  expertise  to  manage  many 
short-duration  projects? 

Do  you  have  a  multi-year  “portfolio-level” 
roadmap? 

Do  you  have  a  12  month  detailed  release 
plan? 

More  emphasis  on 
quicker  decision  making; 
Decisions  will  be  dele¬ 
gated  to  lower  levels  for 
smaller  projects 

New  Approach 
Report 

What  decisions  will  be  delegated  to  lower 
levels?  Will  contractor  be  able  to  make 
more  decisions? 

What  industry  management  practices 
might  you  leverage  to  promote  dynamic 
decision  making?  (e.g.,  Scrum) 

Investment  approach 
will  fund  multiple  time- 
boxed,  overlapping 
projects 

New  Approach 
Report 

What  dependencies  will  there  be  be¬ 
tween  the  “overlapping”  projects  in  the 
portfolio? 

Will  there  be  common  infrastructure  and 
components  in  overlapping  projects? 

Will  projects  have  to  “compete”  for  fund¬ 
ing? 
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Category 

Directive 

Source(s) 

PM  Considerations 

Interrelated  projects  will 
provide  incremental 
iterative  IT  capability 
improvements  through 
frequent  upgrades 

New  Approach 
Report 

How  is  an  “upgrade”  defined? 

How  often  do  you  “upgrade”? 

Is  there  a  fixed  schedule  for  upgrades  or 
is  it  “as  needed”? 

Funding  for  prototyping 
activities  must  be 
planned  and  approved 

Interim  Guidance 

How  do  you  estimate  the  cost  of  proto¬ 
typing? 

Knowledge  gained  dur¬ 
ing  prototyping  may 
result  in  changes  to  the 
requirements 

Interim  Guidance 

Do  your  software  development  and  pro¬ 
cesses  embrace  change? 

Prototyping, 
Requirements,  & 
Architecture 

Requirements  manage¬ 
ment  process  will  be 
adjusted  to  reflect  time- 
boxed  development 
constraints  and  allow  for 
uncertainty 

A  New  Approach 

Do  requirements  management  tools  and 
processes  support  time-boxed  develop¬ 
ment? 

Do  requirements  management  tools  and 
processes  support  uncertainty  or  chang¬ 
ing  requirements? 

Initial  requirements  will 
be  defined  at  the  mis¬ 
sion  level  in  broad, 
measurable  terms  that 
are  not  expected  to 
change  (e.g.,  security, 
data  standards,  perfor¬ 
mance  thresholds  ) 

A  New  Approach 

Is  there  a  good  understanding  of  “mis¬ 
sion  level”  requirements  that  are  not 
expected  to  change? 

Are  the  thresholds  for  measuring  them 
defined? 

Prioritization  and  further 
definition  of  require¬ 
ments  will  be  an  ongo¬ 
ing  activity;  Tools  and 
methods  will  be  fur¬ 
nished  to  prioritize  re¬ 
quirements  and  facilitate 
user  feedback 

A  New  Approach 

Do  your  requirements  tools,  and  pro¬ 
cesses  support  complex  prioritization 
schemes  and  dependency  mapping  by 
feature? 

Do  requirements  tools  and  processes 
incorporate  user  feedback? 

Users  from  joint  or  ser¬ 
vice/agency  organiza¬ 
tions  will  be  designated 
to  actively  participate  in 
oversight  reviews 

A  New  Approach 

If  you  have  a  joint  program,  what  users 
will  actively  participate  in  oversight  re¬ 
views? 

What  will  an  oversight  review  involve  and 
how  will  it  differ  from  traditional  milestone 
reviews? 

Enterprise  focus,  estab¬ 
lished  standards  and 
open  modularity  will 
drive  and  constrain 
designs 

A  New  Approach 

Is  there  a  chief  architect  or  someone 
assigned  to  define  standards? 

Is  there  a  common  definition  for  modular¬ 
ity  and  measurement  criteria  for  achiev¬ 
ing  it? 

Plans  will  be  supported 
by  business  and  tech- 

A  New  Approach 

Who  will  define  technical  architectures 
and  standards  across  a  portfolio? 
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Category 

Directive 

Source(s) 

PM  Considerations 

nical  architectures  and 
standards 

What  process  will  be  used  to  approve 
and  communicate  common  architecture 
components? 

Development  & 
Testing 

Development  and  test¬ 
ing,  when  necessary, 
will  include  prototyping 
and  maturity  assess¬ 
ment  activities 

A  New  Approach 

How  do  you  decide  what  to  prototype? 
What  processes  will  be  used  for  maturity 
assessment?  Do  they  support  iterative 
development? 

Development,  Test  and 
evaluation  will  be  struc¬ 
tured  to  support  iterative 
and  incremental  delivery 
with  user  involvement 

A  New  Approach 

How  to  you  plan  for  incremental  testing? 
What  does  a  continuous  test  process 
look  like?  What  industry  examples  can 
be  leveraged? 

How  does  this  compare  to  traditional 
Operation  Test  &  Evaluation? 

Testing  approaches  will 
make  extensive  use  of 
automated  testing 

A  New  Approach 

Do  you  have  automated  test  tools? 

Does  your  team  know  what  to  automate 
and  what  not  to  automate? 

Do  you  have  expertise  to  build  test 
scripts? 

Testing  will  be  integrat¬ 
ed  with  certification  and 
accreditation  activities 

A  New  Approach 

How  do  you  generate  data  needed  to 
meet  certification  and  accreditation  re¬ 
quirements  in  an  iterative,  incremental 
lifecycle? 

Integrate  existing  test 
infrastructure  into  a 
persistent,  virtual,  ser¬ 
vice-based  environment 

A  New  Approach 

Does  your  testing  approach  and  infra¬ 
structure  support  service-based  testing? 

Is  your  system  designed  to  leverage 
service-based  testing? 

Each  increment  shall 
include  a  close-out  re¬ 
view  to  gain  understand¬ 
ing  of  how  well  a  com¬ 
pleted  increment  meets 
the  needs  of  users 

Interim  Guidance 

What  is  included  in  an  increment  close¬ 
out  review? 

How  will  you  measure  how  well  the  in¬ 
crement  meets  user  needs?  (e.g.,  satis¬ 
faction  survey) 

Introduce  Limited  De¬ 
ployment  Phase  in 
which  limited  number  of 
users  get  access  to  a 
new  “beta”  release; 
Entrance  criteria,  as  per 
the  SecDef  Interim 
guidance,  requires  sys¬ 
tem  to  be  ready  for  initial 
operational  test  and 
evaluation 

Interim  Guidance, 

A  New  Approach 

Will  this  be  a  separate  environment  from 
the  development/integration  test  envi¬ 
ronment? 

How  will  you  gather  and  incorporate 
changes  generated  from  user  testing? 
What  is  the  difference  between  the 

OT&E  requirements  for  limited  deploy¬ 
ment  phase  and  full  deployment  phase 
(guidance  makes  it  sound  like  they  are 
the  same)? 

At  Full  Deployment 
Decision,  the  milestone 
decision  authority  shall 
review  the  Business 

Case,  the  IOT&E  results 
and  DOT&E  recommen¬ 
dations  whether  the 
capability  is  ready  to 
proceed  to  full  deploy¬ 
ment 

Interim  Guidance 

What  iteration  will  be  considered  “full 
deployment”? 

What  does  “full  deployment”  in  an  itera¬ 
tive  lifecycle  mean? 

What  are  IOT&E  criteria  in  a  “continuous 
integration  context”? 
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Category 

Directive 

Source(s) 

PM  Considerations 

Project  Monitor¬ 
ing  and  Report¬ 
ing 

Traditional  milestone 
reviews  to  initiate  major 
DoD  5000  program 
phases  will  be  realigned 
to  frequent  perfor¬ 
mance-based  milestone 
decision  points 

New  Approach 
Report 

What  activities  will  be  conducted  at  fre¬ 
quent  milestone  decision  point  as  op¬ 
posed  to  traditional  milestones?  (e.g., 
demos)? 

What  will  be  used  to  measure  perfor¬ 
mance? 

These  milestone  deci¬ 
sion  points  will  be  con¬ 
ducted  as  in-process 
reviews  for  decision¬ 
makers  to  obtain  real¬ 
time  program  status  for 
acquisition  decisions 

New  Approach 
Report 

How  is  “in-process  review”  defined? 

What  data  will  be  collected  and  used  for 
decision-making? 

Tangible  evidence  of 
relevant  development 
capabilities  in  the  form 
of  prototypes  or  de¬ 
ployed  systems  (“work¬ 
ing  software”)  will  have 
preference  in  an  evalua¬ 
tion  with  a  commensu¬ 
rate  decrease  in  paper- 
based  proposal  compo¬ 
nents 

New  Approach 
Report 

How  will  you  evaluate  “working  software” 
in  an  RFP  evaluation? 

How  will  you  get  access  to  prototypes? 
What  criteria  will  you  use  to  judge  the 
software? 

How  will  you  evaluate  whether  the  pro¬ 
posed  architecture  is  good? 

In  earlier  phases  of  the 
acquisition,  stakeholder 
reviews  should  be  cal¬ 
endar-based  events, 
while  later  phases 
should  link  such  reviews 
with  iterations  or  deliv¬ 
ery  of  capability 

New  Approach 
Report 

Which  activities  will  be  calendar-based 
versus  delivery  based?  (e.g.,  require¬ 
ments  reviews) 

Project  status  and  exe¬ 
cution  information  will  be 
available  online  replac¬ 
ing  paper-based  report¬ 
ing 

New  Approach 
Report 

Will  the  tools  to  publish  project  status  be 
provided  by  the  enterprise,  portfolio  or 
project? 

What  project  status  information  makes 
sense  for  an  iterative  development  ap¬ 
proach? 

Documentation  will  be 
consolidated  into  fewer 
documents 

New  Approach 
Report 

What  documents  do  you  still  need? 

How  do  you  determine  what  is  important 
to  document  about  the  system? 

Technical  Out¬ 
reach 

Outreach  to  industry  will 
be  conducted  to  gain 
insight  into  commercially 
driven  industry  trends 

New  Approach 
Report 

Do  you  collaborate  with  FFRDCs  and 
Industry  to  learn  about  successful  indus- 
try/DoD  practices? 

As  applicable,  innova¬ 
tive  approaches  such  as 
user-centered  design, 
feature-driven  develop¬ 
ments,  and  other  proven 

IT  practices  should  be 
considered 

A  New  Approach 

Do  you  have  a  chief  architect  or  some¬ 
one  identified  that  keeps  up  with  innova¬ 
tive  solutions? 

The  next  section  describes  some  of  the  continued  related  work  in  this  area. 
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6  Continued  Work  on  804  and  IT  Acquisition  Task  Force 


Work  has  continued  in  the  area  of  DoD  acquisition  refonn  since  the  directives  and  guidance  doc¬ 
uments  covered  in  this  paper  were  written.  After  the  release  of  the  2010  Section  804  guidance 
directive,  Congress  continued  to  focus  on  acquisition  reform  by  releasing  the  2011  National  De¬ 
fense  Authorization  Act  titled  “Review  of  Acquisition  Process  for  Rapid  Fielding  of  Capabilities 
in  Response  to  Urgent  Operational  Needs.” 

This  Act  contains  two  major  directives  summarized  below.  These  directives  primarily  focused  on 
making  sure  programs  adopt  the  new  processes  and  that  work  in  the  area  of  developing  the  new  IT 
acquisition  processes  continues  to  evolve  and  mature. 

1 .  The  first  directive  was  a  required  review  of  the  acquisition  process  as  described  in  the  re¬ 
sponse  by  the  Secretary  of  Defense  to  the  2010  Act.  This  Act  specified  that  “Not  later  than 
one  year  after  the  date  of  the  enactment  of  this  Act,  the  Secretary  of  Defense  shall  complete 
a  review  of  the  process  for  the  fielding  of  capabilities  in  response  to  urgent  operational  needs 
and  submit  a  report  on  the  review  to  the  congressional  defense  committees”  [NDAA  2011]. 

2.  The  second  directive  was  a  review  process  examining  which  systems/programs  are  appropri¬ 
ate  for  the  new  acquisition  process  versus  the  traditional  5000.02  process.  The  2011  Act 
specified  that  “Not  later  than  270  days  after  the  date  of  the  enactment  of  this  Act  the  Secre¬ 
tary  shall  develop  and  implement  an  expedited  review  process.  This  process  shall  determine 
whether  capabilities  proposed  as  urgent  operational  needs  are  appropriate  for  fielding  or 
should  be  fielded  through  the  traditional  acquisition  process”  [NDAA  2011],  The  full  text  for 
National  Defense  Authorization  Act  2011,  Section  804  is  provided  in  Appendix  B. 

IT  Acquisition  Task  Force,  chaired  by  the  Deputy  Secretary  of  Defense  and  led  by  the  Deputy 
Chief  Management  Officer  (DCMO),  was  established  to  continue  fleshing  out  the  new  IT  acquisi¬ 
tion  process.  The  original  Task  Force  participants  included: 

•  Under  Secretary  of  Defense  for  Acquisition,  Technology  &  Logistics  (USD(AT&L)) 

•  Assistant  Secretary  of  Defense  for  Networks  and  Information  Integration/DoD  Chief  Infor¬ 
mation  Officer  (ASD(NII)/DoD  CIO) 

•  Director  for  Cost  Assessment  and  Program  Evaluation  (D,CAPE) 

•  Under  Secretary  of  Defense  Comptroller  (USD(C)) 

•  Director,  Operational  Test  and  Evaluation  (DOT&E) 

•  Under  Secretary  of  Defense  for  Intelligence  (USD(I)) 

•  Joint  Chiefs  of  Staff  (JCS), 

•  Military  Departments  (MILDEPs) 

The  Task  Force  engages  with  Congress,  the  Govermnent  Accountability  Office,  and  key  stake¬ 
holders  throughout  the  Department  and  industry  to  further  define  and  implement  the  new  process 
in  accordance  with  this  report.  [New  Approach  2010] 
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The  DoD  and  Federal  CIO  are  also  collaborating  and  continue  to  share  ideas.  Vivek  Kundra,  U.S. 
Chief  Information  Officer  released  the  25  Point  Implementation  Plan  on  the  same  day  the  report, 
A  New  Approach  for  Delivering  Information  Capabilities  in  the  Department  of  Defense,  was  re¬ 
leased.  Many  of  the  concepts  being  promoted  by  the  Federal  CIO  are  consistent  with  the  concepts 
in  the  DoD  directives  (and  vice  versa). 

Some  highlights  of  the  Federal  CIO  25  Point  Implementation  Plan  include  the  following: 

•  Turnaround  or  terminate  one-third  of  underperforming  projects  in  IT  portfolio. 

•  Shift  to  cloud  first  policy. 

•  Reduce  number  of  federal  data  centers  by  at  least  800  by  2015. 

•  Major  IT  programs  must  have  a  dedicated  program  manager  and  use  specialized  IT  acquisi¬ 
tion  professionals. 

•  Use  a  modular  approach  with  usable  functionality  delivered  every  six  months. 

•  Work  with  Congress  to  consolidate  commodity  IT  funding  under  the  Agency  CIOs,  and  de¬ 
velop  flexible  budget  models  that  align  with  modular  development. 

•  Launch  an  interactive  platform  for  pre-RFP  agency- industry  collaboration  [Kundra  2010]. 

The  next  section  contains  some  closing  thoughts  related  to  IT  acquisition  reform  and  ongoing  re¬ 
search  in  this  area. 
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7  Closing  Thoughts 


At  the  time  of  writing  this  summary,  the  804  guidance  for  the  new  DoD  IT  acquisition  process  is 
still  in  its  early  stages  of  maturity.  While  the  good  news  is  the  new  guidance  acknowledges  the 
need  for  DoD  software  acquisition  processes  outside  of  the  DoD  5000.02  traditional  waterfall- 
based  approach,  the  bad  news  is  the  new  DoD  IT  acquisition  process  is  still  largely  undefined.  So, 
program  managers  will  have  to  fill  in  the  gaps  for  a  while. 

In  many  cases,  the  guidance  is  clearly  straddling  the  waterfall  approach  to  managing  IT  acquisi¬ 
tions  while  trying  to  also  encourage  adoption  of  a  new  acquisition  process.  This  is  a  challenging 
situation  for  program  managers.  While  this  straddling  effect  is  expected  for  a  period,  it  will  be¬ 
come  very  burdensome  if  program  managers  have  to  adhere  to  two  sets  of  competing  processes 
for  a  long  time.  It  is  our  hope  that  the  new  acquisition  process  will  become  better  defined  in  the 
near  future  and  that  the  transition  period  when  old  and  new  processes  overlap  will  not  be  too  long. 

In  reviewing  the  Section  804  directives,  we  identified  several  candidate  focus  areas  for  future 
work  described  below. 

1.  Categorization  of  systems  and  characteristics  for  the  new  acquisition  process.  While  the 
“New  Approach”  report  provides  very  high-level,  rough  categorization  of  systems  that  are 
appropriate  for  the  IT  acquisition  process,  there  appears  to  be  a  need  for  continued  work  in 
this  area.  A  more  detailed,  elaborated  model  is  needed  to  reason  about  the  acquisition  pro¬ 
cess  nuances  necessary  to  deal  with  the  wide  variety  of  systems  program  managers  are  build¬ 
ing  today. 

2.  Further  elaboration  of  the  BCL  engineering  phases.  While  the  BCL  provides  significant 
improvement  in  the  areas  of  business  case  approval  and  investment  review,  further,  more  de¬ 
tailed,  guidance  is  required  for  program  managers  to  navigate  the  engineering  phases  (to  in¬ 
clude  phases  such  as  prototyping,  requirements,  architecture,  development,  and  execution). 

3.  Leverage  and  incorporate  industry  practices.  Successful  industry  and  DoD  incremental 
development  practices  should  be  leveraged  and  used  as  models  for  future  IT  acquisition  pro¬ 
cess  and  practice  development. 

The  SEI  is  currently  working  in  these  area  and  we  hope  to  contribute  to  helping  DoD  and  program 
managers  adopt  forward  leaning  acquisition  processes  and  practices. 
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Acronym  List 


BCL  Business  Capability  Lifecycle 
CIO  Chief  Infonnation  Officer 
CJCS  Chairman  of  the  Joint  Chiefs  of  Staff 
DBS  Defense  Business  System 

DBSMC  Defense  Business  System  Management  Committee 
DSB  Defense  Science  Board 

IRB  Investment  Review  Board 

IT  Information  Technology 

JCIDS  Joint  Capability  Investment  Development  System 
OT&E  Operational  Test  &  Evaluation 
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Appendix  A:  National  Defense  Authorization  Act  2010, 
Section  804 


(a)  NEW  ACQUISITION  PROCESS  REQUIRED— The  Secretary  of  Defense  shall  develop  and 
implement  a  new  acquisition  process  for  information  technology  systems.  The  acquisition 
process  developed  and  implemented  pursuant  to  this  subsection  shall,  to  the  extent  determined 
appropriate  by  the  Secretary — 

( 1 )  be  based  on  the  recommendations  in  chapter  6  of  the  March  2009  report  of  the 
Defense  Science  Board  Task  Force  on  Department  of  Defense  Policies  and  Procedures 
for  the  Acquisition  of  Information  Technology;  and 

(2)  be  designed  to  include — 

(A)  early  and  continual  involvement  of  the  user; 

(B)  multiple,  rapidly  executed  increments  or  releases  of  capability; 

(C)  early,  successive  prototyping  to  support  an  evolutionary  approach;  and 

(D)  a  modular,  open-systems  approach. 

(b)  REPORT  TO  CONGRESS — Not  later  than  270  days  after  the  date  of  the  enactment  of  this 
Act,  the  Secretary  of  Defense  shall  submit  to  the  Committees  on  Armed  Services  of  the  Senate 
and  the  House  of  Representatives  a  report  on  the  new  acquisition  process  developed  pursuant  to 
subsection  (a).  The  report  required  by  this  subsection  shall,  at  a  minimum — 

(1)  describe  the  new  acquisition  process; 

(2)  provide  an  explanation  for  any  decision  by  the  Secretary  to  deviate  from  the  criteria 
established  for  such  process  in  paragraphs  (1)  and  (2)  of  subsection  (a); 

(3)  provide  a  schedule  for  the  implementation  of  the  new  acquisition  process; 

(4)  identify  the  categories  of  information  technology  acquisitions  to  which  such  process 
will  apply;  and 

(5)  include  the  Secretary’s  recommendations  for  any  legislation  that  may  be  required  to 
implement  the  new  acquisition  process. 
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Appendix  B:  National  Defense  Authorization  Act  2011, 
Section  804 


From  H.  R.  6523 

SEC.  804.  REVIEW  OF  ACQUISITION  PROCESS  FOR  RAPID  FIELDING  OF 
CAPABILITIES  IN  RESPONSE  TO  URGENT  OPERATIONAL  NEEDS. 

(a)  Review  of  Rapid  Acquisition  Process  Required- 

( 1)  IN  GENERAL-  Not  later  than  one  year  after  the  date  of  the  enactment  of  this  Act,  the  Secre¬ 
tary  of  Defense  shall  complete  a  review  of  the  process  for  the  fielding  of  capabilities  in  response 
to  urgent  operational  needs  and  submit  a  report  on  the  review  to  the  congressional  defense  com¬ 
mittees. 

(2)  REVIEW  AND  REPORT  REQUIREMENTS-  The  review  pursuant  to  this  section  shall  in¬ 
clude  consideration  of  various  improvements  to  the  acquisition  process  for  rapid  fielding  of  capa¬ 
bilities  in  response  to  urgent  operational  needs.  For  each  improvement,  the  report  on  the  review 
shall  discuss— 

(A)  the  Department's  review  of  the  improvement; 

(B)  if  the  improvement  is  being  implemented  by  the  Department,  a  schedule  for  implementing  the 
improvement;  and 

(C)  if  the  improvement  is  not  being  implemented  by  the  Department,  an  explanation  of  why  the 
improvement  is  not  being  implemented. 

(3)  IMPROVEMENTS  TO  BE  CONSIDERED-  The  improvements  that  shall  be  considered  dur¬ 
ing  the  review  are  the  following: 

(A)  Providing  a  streamlined,  expedited,  and  tightly  integrated  iterative  approach  to— 

(i)  the  identification  and  validation  of  urgent  operational  needs; 

(ii)  the  analysis  of  alternatives  and  identification  of  preferred  solutions; 

(iii)  the  development  and  approval  of  appropriate  requirements  and  acquisition  docu¬ 
ments; 

(iv)  the  identification  and  minimization  of  development,  integration,  and  manufacturing 
risks; 

(v)  the  consideration  of  operation  and  sustainment  costs; 

(vi)  the  allocation  of  appropriate  funding;  and 

(vii)  the  rapid  production  and  delivery  of  required  capabilities. 

(B)  Clearly  defining  the  roles  and  responsibilities  of  the  Office  of  the  Secretary  of  Defense,  the 
Joint  Chiefs  of  Staff,  the  military  departments,  and  other  components  of  the  Department  of  De¬ 
fense  for  carrying  out  all  phases  of  the  process. 

(C)  Designating  a  senior  official  within  the  Office  of  the  Secretary  of  Defense  with  primary  re¬ 
sponsibility  for  making  recommendations  to  the  Secretary  on  the  use  of  the  authority  provided  by 
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subsections  (c)  and  (d)  of  section  806  of  the  Bob  Stump  National  Defense  Authorization  Act  for 
Fiscal  Year  2003  (10  U.S.C.  2302  note),  as  amended  by  section  803  of  this  Act,  in  appropriate 
circumstances. 

(D)  Establishing  a  target  date  for  the  fielding  of  a  capability  pursuant  to  each  validated  urgent  op¬ 
erational  need. 

(E)  Implementing  a  system  for— 

(i)  documenting  key  process  milestones,  such  as  funding,  acquisition,  fielding,  and  assessment 
decisions  and  actions;  and 

(ii)  tracking  the  cost,  schedule,  and  perfonnance  of  acquisitions  conducted  pursuant  to  the  pro¬ 
cess. 

(F)  Establishing  a  formal  feedback  mechanism  for  the  commanders  of  the  combatant  commands 
to  provide  information  to  the  Joint  Chiefs  of  Staff  and  senior  acquisition  officials  on  how  well 
fielded  solutions  are  meeting  urgent  operational  needs. 

(G)  Establishing  a  dedicated  source  of  funding  for  the  rapid  fielding  of  capabilities  in  response  to 
urgent  operational  needs. 

(H)  Issuing  guidance  to  provide  for  the  appropriate  transition  of  capabilities  acquired  through  rap¬ 
id  fielding  into  the  traditional  budget,  requirements,  and  acquisition  process  for  purposes  of  con¬ 
tracts  for  follow-on  production,  sustainment,  and  logistics  support. 

(I)  Such  other  improvements  as  the  Secretary  considers  appropriate. 

(b)  Discriminating  Urgent  Operational  Needs  From  Traditional  Requirements- 

(1)  EXPEDITED  REVIEW  PROCESS-  Not  later  than  270  days  after  the  date  of  the  enactment  of 
this  Act,  the  Secretary  shall  develop  and  implement  an  expedited  review  process  to  determine 
whether  capabilities  proposed  as  urgent  operational  needs  are  appropriate  for  fielding  through  the 
process  for  the  rapid  fielding  of  capabilities  or  should  be  fielded  through  the  traditional  acquisi¬ 
tion  process. 

(2)  ELEMENTS-  The  review  process  developed  and  implemented  pursuant  to  paragraph  (1)  shall- 

(A)  apply  to  the  rapid  fielding  of  capabilities  in  response  to  joint  urgent  operational  need  state¬ 
ments  and  to  other  urgent  operational  needs  statements  generated  by  the  military  departments  and 
the  combatant  commands; 

(B)  identify  officials  responsible  for  making  determinations  described  in  paragraph  (1); 

(C)  establish  appropriate  time  periods  for  making  such  determinations; 

(D)  set  forth  standards  and  criteria  for  making  such  determinations  based  on  considerations  of 
urgency,  risk,  and  lifecycle  management; 

(E)  establish  appropriate  thresholds  for  the  applicability  of  the  review  process,  or  of  elements  of 
the  review  process;  and 

(F)  authorize  appropriate  officials  to  make  exceptions  from  standards  and  criteria  established  un¬ 
der  subparagraph  (D)  in  exceptional  circumstances. 

(3)  COVERED  CAPABILITIES-  The  review  process  developed  and  implemented  pursuant  to 
paragraph  (1)  shall  provide  that,  subject  to  such  exceptions  as  the  Secretary  considers  appropriate 
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for  purposes  of  this  section,  the  acquisition  process  for  rapid  fielding  of  capabilities  in  response  to 
urgent  operational  needs  is  appropriate  only  for  capabilities  that— 

(A)  can  be  fielded  within  a  period  of  two  to  24  months; 

(B)  do  not  require  substantial  development  effort; 

(C)  are  based  on  technologies  that  are  proven  and  available;  and 

(D)  can  appropriately  be  acquired  under  fixed  price  contracts. 

(4)  INCLUSION  IN  REPORT-  The  Secretary  shall  include  a  description  of  the  expedited  review 
process  implemented  pursuant  to  paragraph  (1)  in  the  report  required  by  subsection  (a). 
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